Mac100% 1998 November/MAC100-1998-11.ISO.7z/MAC100-1998-11.ISO/ｵﾝﾗｲﾝｿﾌﾄ定点観測/ﾕｰﾃｨﾘﾃｨ/Shane the Plane 2.0.2.sit/Shane the Plane 2.0.2/Fly SAFE with Shane the Plane!

Text File | 1998-08-01 | 74KB | 1,436 lines

Fly SAFE with Shane the Plane!

(A Power User's manual for Power User's software)


Documenting: Shane the Plane (version 2.0.2) ｩ 1998 by Greg Swann

8/1/98

Greg Swann

[e-mail]
[e-mail]

USPS: 3608 West Cochise Drive
      Phoenix, AZ 85051




Table of Contents

0. Entirely UNFAIR warnings...

1. Introductory Chatter...

2. Commercial, legal and other pertinent notices...

3. Shane the Plane - the quick hop...

4. Transcontinental Shane the Plane...

5. Not for Flight Engineers only...

6. About Greg Swann...

7. Conclusion...

Appendix: Real World Shane the Plane by Kip Shaw




0. Entirely UNFAIR warnings...

Don't say you weren't warned: This software is DANGEROUS!

Repeating: THIS SOFTWARE IS DANGEROUS!!

Nothing is buggy. Everything works as documented. But: almost everything
we're doing here is _inherently_ dangerous. This is most emphatically
_NOT_ intended to be used by novices. This is Power User's software
intended to be used by Power Users. There is nothing being done here
that could not be done by other (much slower) means, but many of the
functions performed by Shane the Plane would require special software
and a deep knowledge of Macintosh topology. Shane the Plane offers fast,
convenient brute-force to people who _could_ do these jobs manually. If
you could not, do yourself (and your "guru") a favor and drop out now.
It's no stain to save yourself unnecessary pain (grin).

There will be little warnings all the way through this manual, but I
wanted to establish a Global Warning Trend (groan!) right at the top: if
you don't know what the hell I'm talking about in this document (and I'm
deliberately not making things too easy), take that as your cue that
this is not for you. I'm not trying to talk my way out of your money,
but I surely don't want your money for giving you the means to
irreparably damage your files (taking careful note that it will be your
own damn fault if your do!).

On the other hand: if you _are_ a Macintosh adept, hang in. This is
definitely a jet-powered file-attribute management utility. The whole
point is learning to Fly SAFE with Shane the Plane...



1. Introductory Chatter...

This is a further development on the gross concept of the original Shane
the Plane (version 1.0.x), a FreeWare program that can be found on
CompuServe and other electronic information services. The original Shane
the Plane optionally changed the creator and type of files, and/or their
created/modified dates and times. Shane the Plane version 2.0.2, this
software, continues to do that stuff, but it also intelligently renames
files, inserts the file's name as a "slug" in text files, and permits
really radical batch editing of significant Finder flags (for example,
you can "Paste" custom icons into a huge batch of files very quickly).

The original FreeWare Shane the Plane is available and will always be
available for free. But: Shane the Plane 2.0.2 is commercial software:
you can't use it (for long) without paying me. The copy of Shane the
Plane in this archive is a DemoWare version that will permit up to 32
launches and then forevermore refuse to do anything but be an automated
salesman. It is a _fully functional_ demo. Nothing is crippled. The only
inhibition is the one named: 32 launches, max. See "Commercial, legal
and other pertinent notices" below for information on how to purchase
unrestricted copies of Shane the Plane.


This software is named for Shane Stanley, de facto product manager for
all of my commercial programs and the quiet voice of reason behind
virtually everything I do. Shane has been unstinting in the benefits he
has conferred upon me, and I can never hope to repay him. We've worked
together for a little over a year, and in that time my respect for him
has grown geometrically. He's a very valuable business associate (to the
extent that you can call what I do a business), but _much_ more
important, he's a very highly valued friend. I'm proud to have produced
a piece of software that is _almost_ worthy of its namesake.

Here's the story: when we were working on version 1.0.0 of Shane the
Plane, I was casting about for a name. I had already written two pieces
of software named after Shane, but neither was released - the second
because it was trivial and the first because it was a little too
user-friendly... But I wanted to name something (useful) in his honor,
and I'd been waiting for the right thing. It happens that I was talking
to my four-year-old daughter, Meredith, (in a very general way) about
this project, and I asked her what I should call it. "Shane the Plane,"
she said, that being her name for all airplanes. Shane's name comes up
in conversation a lot, and she worked out the rhyme on her own. And
names for "things" are a big deal right now; the computer I'm working on
is named "Amber", after Meredith's favorite kind of traffic light. Meri
made the original icon, a biplane painted brown to blend into the rugged
outback of Shane's native Australia. She also made the jet icon that
graces this version.

With some validity, this could be named after Kip Shaw, since it was he
who got me thinking about many of the problems it solves. Notably,
creator/type changing, intelligent file renaming, and text file
"slugging" are all responses to conversations with Kip about things we'd
like to be able to do. Renaming and slugging are pieces of a software
puzzle Kip is putting together to automate a significant part of his
publishing work. Another piece of that same puzzle is the FreeWare
program ShawBerry, named after Kip, which is stored on CompuServe (as
BERRY.CPT in Library 5 of the DTPForum) and other electronic information
services.


Shane and Kip were the beta testers for this version of Shane the Plane,
and, as always, they have my gratitude. Even more than "always",
perhaps, since they were testing a huge piece of software that was
largely in flux until the bitter end.


TechnoBabble: Shane the Plane is compatible with Systems 8, 7 and 6. It
is AppleEvent-aware, so, presumably, you could script to it from an
intelligent agent. It's 32-bit clean, MultiFinder aware, a real fun date
- all the usual stuff. In short (there will be much more later), it's
everything you expect of up-to-the-microsecond Macintosh software.


New in this version: Version 2.0.2 implements only two changes: We fixed
a tiny bug in the case conversion routines in 'Rename with wildcards'
and we updated the ordering information (and this manual) to reflect our
assocation with www.kagi.com, an automated software ordering fulfillment
service.


Notes on this text: this file is written as plain text in DOS-like
fashion (i.e., every line ending is a carriage return). It is produced
in a FreeWare Programmer's editor called BBEdit by Rich Siegel (which is
recommended). I've had mail about this, so I'll explain: I produce
documents this way because doing so makes no presumptions about what
software and fonts you might own. _Most_ word processors can open, e.g.,
MS-Word files. But _all_ word processors can open _this_ file.



2. Commercial, legal and other pertinent notices...

As mentioned above, this is a DemoWare version of Shane the Plane, fully
functional but limited to 32 launches. The full unrestricted commercial
release can be obtained from Greg Swann at:

    3608 West Cochise Drive
    Phoenix, AZ 85051

Licenses are sold per machine, with a single license costing $50;
2-10 licenses are $45 each; and for 11 or more licenses you're
better off buying a site license. All of this is explained in the
registration software supplied with this archive.

Why is this version DemoWare? As with everything in my life, there is
philosophy here: I don't like crippled software. I don't think much of
ShareWare. And I almost never buy "a pig in a poke". In deciding on a
marketing scheme, I looked for something that would be most appealing to
_me_, were I in your shoes. This is what I've come up with: a fully
functional demo that lets you _find out_ if Shane the Plane is a useful
tool in your working environment. If it is (and obviously _I_ think it
will be), then pay me. If it isn't, then ditch it when it starts to
offer to make coupons for you as a full-time gig. A good deal all
around, I think: no guilt for you, no guilting for me; maybe useful
software for you, maybe useful money for me (grin).

Shane the Plane, its source and executable code, and this poor excuse
for a manual are Copyright (C) 1998 by Greg Swann. All rights are most
emphatically reserved.

The unrestricted (non-DemoWare) version of Shane the Plane is licensed
for use on one machine by the person who paid for it. If you didn't pay
for it, please do! I am one person, with a long-suffering family, not
Conglomerated MegaSoft (not to imply that there's any virtue in ripping
_them_ off!).

Shane the Plane is delivered "as is", without any warranties, expressed
or implied. It is not warranted to be useful _to_ anyone, _for_
anything, and in no wise am I to be held responsible for any unfortunate
consequences resulting from its use or misuse. And I _hate_ having to
say things like that. I do my best to write useful, simple, elegant,
bug-free solutions to difficult problems. If you take it into your head
that I represent your big chance to "strike it rich", you will pay a lot
in legal fees to discover that you have miscalculated.

And: to those to whom the above disclaimers do not apply: forgive me for
having to make them. It's _you_ whom I'm working for, for pay or for
free. I appreciate your patronage and your support, and I wish we all
could just comb the others out of our hair...

(Hey, it's a real 'personal' software company! (grin))



3. Shane the Plane - the quick hop...

This is an accelerated introduction to Shane the Plane's features and
functions. Frankly, I think you should read the detailed instructions
below. But if you're simply in _too_ big a hurry, this will get you
airborne with Shane the Plane.

Here's what you do: Drag & Drop _copies_  of some files on the icon or
an alias of it. Set some switches. Hit Start. If the results aren't all
you dreamed, try again. Hammer away all afternoon, if necessary. This is
the _Mac_, dammit, and we are constitutionally exempted from reading
manuals, even when doing so would be _far_ faster than "intuiting"...
(wry grin)

Seriously: if you reason well, you can puzzle this out on your own. But:
if you reason well, perhaps a word to the wise will be sufficient: This
software is DANGEROUS!

In other words, _please_ take the time to find out what all these
controls and switches do. Noodle around with copies of files until
you're comfortable with the jobs you'll be doing. Back off and re-read
as soon as something you hadn't expected happens. Commit yourself to
this software _only_ when you've committed its behavior to memory. By
being modal (to the point of user-hostility in places) we're insulating
you from the worst consequences. But the next-to-worst are very far from
good, and I'd hate for anyone to "quick-start" their way into a slow
restoration...

...now do as you will.



4. Transcontinental Shane the Plane...

(If you use other software by me, there are a couple of big differences
in Shane the Plane from my normal methods. First, because it seemed
likely to me that few Shane the Plane jobs would use the previously
established preferences, you _must_ hit the Start button for execution
to begin on a Drag & Drop batch of files. In other words, my expectation
is that nearly every job will require some switch-setting, so the
default behavior is to make you explicitly assert your readiness to
begin by hitting the Start button. Second, all of the changes made by
Shane the Plane are done "in place"; no new files are created. Normally,
my stuff copies from the source file to a new (uniquely named)
destination file, leaving the source untouched. Since Shane the Plane
exists to modify pre-existing files, that is not done here. This is not
terribly important except for this: if something goes badly wrong, your
file(s) may be toasted. We are watching our own butt (and yours), but
there's no accounting for acts of nature, etc. In truth, where we are
doing dangerous things, we are doing them in the same way they are done
by software costing 10 times as much as Shane the Plane. But: be careful
anyway. If a file is irreplaceable, then work on a copy, replacing the
original only when you're sure all is well. (This is good advice in
general!))

Shane the Plane runs out of a single dialog box, plus the menu bar.
About and Quit are familiar to everyone. The Command key equivalents for
Copy, Paste, and Cut work. Restore defaults restores all settings to
their "factory" defaults. Restore saved preferences restores the
settings to those most recently saved. And Save preferences saves the
current settings as the future defaults to use at launch time. In other
words, if you have a set of operations you do endemically, make those
your saved preferences. Then, when you have a job that doesn't fit the
mold, make temporary changes, execute the job, and quit without saving
the preferences.

There is a special logic to the way Shane the Plane handles files
delivered by Drag & Drop (available with System 7 and above). Works like
this:

1. If Shane the Plane is launched by means of Drag & Drop, the settings
you establish are applied to that batch of files when you hit the Start
button, and then Shane the Plane quits without having to be told to
quit.

2. If you launch by double-clicking on the icon (or an alias of it),
then Shane the Plane must be quit explicitly (that is, you must select
Quit from the File menu or type Command-Q). If you hit the Start button
(without having Dragged & Dropped files), you will be presented with a
Standard File dialog box from which you can select _one_ file, which
will then be processed with the settings you have established (this is
the only way of using Shane the Plane with System 6). On the other hand,
if you double-click launch and then Drag & Drop files, the settings you
establish are applied to that batch of files when you hit the Start
button, but Shane the Plane _does not_ Quit on its own at the end of the
batch.

(There is one exception to this logic: when you have Dropped a batch of
files, a "Clear batch" button becomes visible. If you hit that button,
the batch of files will be cleared from memory, and Shane the Plane will
revert to the interactive state. In other words, if you launch with a
Drag & Drop batch, the software will Quit automatically after processing
if you hit Start, but will _not_ Quit if you hit Clear batch.)

In this way you get the best of all worlds: quick, non-intrusive Drag &
Drop, fully interactive operation, or interactive Drag & Drop.

(Important: when files are processed by Drag & Drop, we are giving you a
great deal of information about their native state (viz., creator and
type, current Finder flags settings, file names, etc.). We can't give
you this news about files processed interactively (the System 6 way),
since we but barely know it before it's old news. The _best_ reason to
use Shane the Plane by Drag & Drop is that it's _much_ faster. But this
is _another_ reason: it's a much more information-rich (hence safer) way
to fly...)

(Also important: certain features of Shane the Plane take advantage of
Finder features available _only_ with System 7 and above. These are:
Lock file name and the three check boxes relating to custom icons. These
check boxes will be disabled if you launch with System 6.)

In the dialog, there are five primary check boxes that govern the
behavior of the subsidiary controls indented beneath them. If the
primary check box is checked, the controls beneath are honored;
otherwise they're ignored. The "factory" settings for the primary check
boxes have them all unchecked. If you make any demonstrably affirmative
change to a subsidiary control, the appropriate primary control will be
checked automatically. The primary check boxes are these:


Change creator/type: changes the creator and type of the file(s)
selected (surprise). The two text fields beneath the check box allow you
to establish which Creator and Type codes to use. These default to
'R*ch' and 'TEXT' because that's what I need most often (and whom should
I please if not myself? (grin)). You can use '****' as a wildcard
meaning, "Stet. Leave this field the way it is". If you Drag & Drop
files, the Geneva text under the text fields is the creator and type of
the _first_ file in the batch. Reasonably intelligent error-checking is
going on in these fields when you hit the Start button.


Change Finder flags: This is very complicated, so we're going to come
back to it after dispensing with the others.


Change date/time: The Change date/time check box controls whether or not
the created and modified dates of the file(s) will be altered. If
checked, both will be changed to the same date and time. The format
shown in Geneva beneath the text fields is a reflection of your Control
Panel date set-up. If you're set up for U.S.-style dates, you'll see
"MM/DD/YY", and you must enter dates that way. If you're set up for
non-U.S.-style dates, you'll see "DD/MM/YY", and you'll enter dates that
way. No matter what, the times must be entered as "HH:MM:SS", using a
24-hour clock (i.e., the second before midnight is 23:59:59, and the
second after midnight is 00:00:01). Reasonably intelligent
error-checking is going on in these fields when you hit the Start
button.

The date/time pop-up requires a bit of explanation because it does two
things. First, it establishes the form that the date and time will take
on the next launch (if you Save preferences). But it _also_ gives you 10
plug-and-play options to use on the fly. Use preferences uses the
strings from the most recently saved preferences, _not_ the result of
the saved state of the pop-up itself. Likewise for Use defaults. These
are provided so that you can store literal dates and times, as opposed
to the software-generated forms used by the others.

Clear as mud? Here's the deal: we're actually "storing" the dates and
times in two ways in the preferences. We're storing the current switch
setting of the pop-up, _and_ we're storing the actual text of the
editable fields. If you set the pop-up to Today at midnight, but _then_
enter "01/02/98" in the date field, and then Save preferences, when you
launch again, things will be thus: the pop-up and the date shown will
reflect Today at midnight for every midnight of every today for all
eternity. But: if you select Use preferences, you'll see "01/02/98".
This will remain, steady as a rock, until the next time you Save
preferences. This was done this way for a reason: suppose you want to
modify work done over several days so that it all has the same date
applied to it. You could wait and do the whole batch all at once. Or you
could take advantage of this feature to date-stamp it as you go along.
This feature is so well thought out that _no one_ understands it! (grin)
Play with it in connection with Save preferences, and you'll see what's
going on.

(And a brief word about date modification: it would be very easy to use
this feature for fraudulent purposes. You could claim to have started
something before you really did, swear up and down that you didn't make
a change that you _did_ make, divert accusing fingers of blame toward
unsuspecting innocents. This is one of the reasons that Created and
Modified are not independently editable: I can't think of an honorable
reason why anyone would need to do this. But, even so, it's still
possible to commit fraud with Shane the Plane, and all I can say is
this: I hope you don't. The finite time of your life is your only asset,
and I would hope you wouldn't choose to squander it with ego-destructive
acts...)

(And another brief word about date modification: certain disk repair
utilities (notably The Norton Utilities) don't like files with odd
dates. If you use this time machine to move files to the distant past,
or to any point in the future, prepare to face a quizzical modal dialog
from your disk fixer. No consequences, just an opportunity to fix or
ignore.)

(And a final word about date modification: what's it for? Sex appeal,
that's all. When you're delivering work that's twice-slick in every
other respect, it's thrice-slick to have every file set to the same date
and time. Software developers reading this will know _exactly_ what I
mean. Racing stripes don't make sports cars _run_ any faster; they just
make them _sell_ faster (grin).)


Change file names: Here am I hoist by my own petard! As discussed below
in "About Greg Swann", I write a lot of file conversion utilities. Each
of these makes its own files from the source files, adding its own
"extension" to make a unique file name. What's worse, many of these are
eminently useful if used in combination. It's very easy to have a file
called "theFile.TQM.XP8.TQM.SB!". Many of the options in Change file
names exist to contain this mad proliferation of extensions.

In the pop-up menu, you have these choices:

Prompt individually - presents a dialog showing the current file name
and inviting you to change it manually.

Use text fileﾕs slug line - intelligently parses the slug line inserted
by a prior pass through Shane the Plane (see "Insert slug line in text
files" below). If a Shane the Plane slug line is not found, this renames
the file with text from the file. The method of selecting text is this:
starting from the first non-white-space character, assemble up to 31
characters of text or up to the next return character found, omitting
any trailing whitespace characters. In all cases, colons are converted
to hyphens (since the colon is the path separator in the Mac OS), and
control characters are converted to space-bands.

(If the file is _not_ of type 'TEXT', the name will not be changed.
Depending on the state of the Auto-pilot|Prompt radio group, Shane the
Plane-inserted slug lines are either omitted or retained. If the slug
line was not inserted by Shane the Plane (viz., if we are just using
text from the top of the file), the slug is not omitted. If Auto-pilot
is selected, and if we find a Shane the Plane-inserted slug line, then
the slug line and any trailing white space characters are removed. If
Prompt is selected, you will be prompted (once per session) as to
whether you want to retain or omit Shane the Plane-inserted slug lines.
This was done so that, if you are inserting slug lines for temporary
reasons, you can get them back out efficiently.)

Remove all extensions - removes all extensions, from last to first. For
all of these menu entries, an extension is defined as non-white-space
characters at the end of the file name, fingering backward to a period
character. The extension of "theFile.txt" is ".txt", but "theFile.txt
Copy" _does not have an extension_, since there is a white-space
character between the end of the line and the period. In all cases, we
retain any text that does not fit this definition. If you ask to have 3
extensions removed and only 2 are found, only those 2 will be removed.
We're being extra-careful about this, because injudicious use of this
function could result in the loss of files.

Remove all but 1st ext. - would convert "theFile.TQM.XP8.TQM.SB!" to
"theFile.TQM".

Remove last ext. - would convert "theFile.TQM.XP8.TQM.SB!" to
"theFile.TQM.XP8.TQM" or "theFile.TQM" to "theFile".

Remove last 2 exts. - would convert "theFile.TQM.XP8.TQM.SB!" to
"theFile.TQM.XP8".

Remove last 3 exts. - would convert "theFile.TQM.XP8.TQM.SB!" to
"theFile.TQM".

Custom extension - uses the text entered in the Extension text field
below the pop-up. Both Extension and Prefix are limited to four
characters, and a reasonable amount of error-checking is going on when
the Start button is hit.

(Why four characters? Since a Macintosh file name is limited to 31
characters in length, even four characters represents a significant
fraction of its total size. The longer an extension or prefix is, the
greater the likelihood of introducing duplicate file names. Shane the
Plane adds _only_ the number of characters actually typed in the field.
So, for example, the default Prefix ("･ ") adds only two characters. If
you really want a much longer prefix or extension (which I think is a
Bad Idea (not, mind, a Real Bad Idea)), load it into the paste buffer
and use Prompt individually, pasting it into each name. Alternatively,
run twice with different text in the affected field. Or see 'Rename with
wildcards' below.)

Custom, removing exts. - same as above except that all pre-existing
extensions are removed before the new one is tacked on.

Prefix - works like Custom extension except that the Prefix is put at
the _front_ of the file name. This can be useful for forcing a sort
ordering in List by Name view in the Finder, etc.

Prefix, removing exts. - take the previous two and interpolate (grin).

Remove prefix - removes a file name's prefix in a fairly tightly defined
sort of way. The problem is this: extensions are pretty much an accepted
standard, going back to Unix and before. We can all agree what an
extension looks like and respond accordingly. But the concept of
prefixing file names is new with the Mac, and there really isn't any
accepted practice about how to do it. So what we're doing is this:
first, we're examining the Prefix text field. If the first N characters
of the file name match the N characters of the Prefix you've typed, we
are omitting those N characters. That means that _you_ can establish
what you want removed by typing into the Prefix text field. Second, if
that test fails, we are looking for a prefix in the form of: 1 non-white
space character immediately followed by 1 white space character (e.g.,
"* "). A non-white space character is any legal file-naming character
_other_ than space or option-space. A white space character is either
space or option-space, nothing else. If the file name matches that
"mask", we remove the first two chararters (only) of the file name.

Rename with wildcards - uses Torquemada's syntax to give you a batch
renaming capability such as the DOS- and UNIX-heads are always boasting
about. Rub their noses in this, because it's _much_ more powerful.
Unfortuantely, it's somewhat more complicated, first because Mac
filenames are larger and more flexible than what passes for filenames
under DOS, and second because Torquemada's complexity can leave users
somewhat at sea. This feature was requested by Mike Arst and was added
with version 2.0.1. It is extremely Arstian in its form, so, if you
don't feel perfectly comfortable with it, just walk on by. Me feeling is
that it has the potential to be immensely time-saving once in a blue
moon, which scores it as a win in my book. If not in yours, it's cool.
Really. (grin)

No business like UI business: if you select this in the pop-up, when you
hit the Start... button you will be prompted for a source filename mask
and a destination filname mask. These are analogous to Torquemada search
and replace strings, and, in fact, they are entered in exactly the same
way. If you're working interactively and you pop-up out and back in, you
will be prompted for new masks. Otherwise, the masks will persist
indefinitely (that is, until you Quit). Obviously, when you D&D you're
only going to see them once, no matter what.

At the time the renaming business happens, the current filename plus the
two masks are delivered to code that is, in fact, culled as is from
Torquemada 1.2.2. In other words, in principle, every TQM 1.2.2 S&R
operation can be done to your filenames. In practice, there are some
limitations. If your filename ends up longer than 31 characters,
something must be done. If Auto-pilot|Prompt is set to Prompt, you will
be prompted for intervention. If Auto-pilot is set, the name will be
truncated mercilessly at the 31st character. Obviously, you're never
going to get a colon (":") into a filename, since that is the one
illegal character in Mac filenames (another big score on D(uh)OS).
Certain Torquemada constructs are meaningless (e.g., "^t" (tab) and "^p"
(return)), since Shane the Plane insulates _all_ control characters in
filenames as spacebands. And, finally, prior to System 8, the Mac OS
ignored without comment name-change requests that entailed _only_
changes in case. In other words, the case-changing TQM commands would
_work_, but you have to change more than the case to get the Mac OS to
concede that a change should really happen. _Any_ change is sufficient;
a trailing space, a leading bullet, a change in spelling - anything that
makes the old and new names different when case is ignored.

The manual that ships with Torquemada 1.2.2 runs to about 12,000 words,
rather more space than I want to devote to one feature of Shane the
Plane. So for a fuller understanding of the commands summarized below,
refer to the Torquemanual. Incidentally (and mercenarily), if you're
using Torquemada 1.1.0 (the FreeWare version), this list should make
plain why you should upgrade: the stuff that's new is way powerful.

RENAME WITH WILDCARDS QUICK REFERENCE

ALIASESﾑMatch special text characters
  ^T or ^t    Tab
  ^P or ^p    Carriage return
  ^^          Caret
  ^ú          ú  ({OPT-h})
  ^û          û  ({OPT-k})

UNTYPED WILDCARDSﾑMatch any one character
  ^0, ^1, ^2, ^3, ^4

TYPED WILDCARDSﾑMatch any one character of that type
  ^+    Uppercase character (includes accented characters)
  ^-    Lowercase character (includes accented characters)
  ^ｱ    Character of either case (includes accented characters)
  ^&    Alphanumeric character (letter or number, not space or punctuation)
  ^%    Tabular character (digit, space or punct.; not alphabetical)
  ^$    Printable character (all characters _except_ space characters)
  ^｢    Any character _EXCEPT_ return
  ^!    Punctuation character (includes high-ASCII punctuation)
  ^.    Sentence Punctuation character (.,;:!?)
  ^#    Numeric character (digits only)
  ^_    Space character (space, return, tab, option space)
  ^ﾂ    Space character (space, tab, option space, but _NOT_ return)

DO-IT-YOURSELF WILDCARD-Match any one character of the type you define
  ^ﾇ...ﾈ    "..." is your definition

WILDSTRINGSﾑMatch and store any text until full pattern is matched
  ^*, ^~, ^?, ^@

THE WILDSTRING MODIFIER-Constrain following wildstring to type of
                        preceding wildcard or character
  ^<

CASE CONVERSION COMMANDSﾑCan be used only on the replace side;
                         accented characters are handled
                         intelligently
  ^C or ^c    CONVERT TO ALL CAPS
  ^L or ^l    convert to all lower case
  ^S or ^s    Convert to sentence caps
  ^U or ^u    Convert To Upstyle Caps
  ^D or ^d    Convert to Downstyle Caps
  ^=          Cancel all case conversion

If you Drag & Drop files, the name of the _first_ file will appear in
Geneva below the Prefix and Extension fields before you hit Start. After
you hit Start, the names of the files in the batch will be shown in
sequence as they are processed.

The Auto-pilot|Prompt radio button group controls how Shane the Plane
deals with untoward file naming events. If the newly created name is the
same as that of a file that already exists in the destination folder,
that other file will either be replaced automatically or you will be
prompted for action, depending on the state of this radio button. If
adding a Prefix or Extension would result in a file name longer than 31
characters (the Mac max), the name will either be truncated
automatically, or you will be prompted for action. If it is truncated
automatically, the truncation will happen to the _base_ name, _before_
the addition of the new text. In this way (with Extensions), you
preserve the characters you're trying to add! As discussed above, the
Auto-pilot|Prompt radio group determines whether you will be prompted to
discover if you want to omit Shane the Plane-inserted slug lines when
Use text file's slug line is selected, or if you want them to be omitted
automatically. Finally, if the new name is exactly the same as the old
name, the renaming will either be skipped or you will be prompted for
action, depending on the state of this radio button. My advice: leave it
set to Prompt (the factory default). You won't be prompted that often,
but Murphy's Law of Disk Recovery Software says that the only file that
can't be recovered is the one that can't be replaced. The File You Save
May Be Your Own!

(About "Prompting": this is all run out of a smart dialog that tells you
what it wants you to do and won't let you do anything illegal. It's
oppressively modal, but there is nothing in Mac-land that is quite so
modal as naming files.)

(Modal: This is so much a part of the Mac landscape that we tend not to
notice it. The thing that makes character-oriented software so loathsome
to use is its overuse of "modes". You can't select when you're in the
insertion mode; you can't type when you're in the selection mode. Mac
software is modeless wherever possible, introducing modes _only_ where
modelessness would be inherently dangerous. A Macintosh mode is denoted
by a modal dialog box, and you _must_ legally dismiss that dialog before
you can proceed. Thoughtful handling of modelessness and modes is what
separates the sheep from the lambs among Graphical User Interfaces. More
than anything else, this is what makes also-rans like Windows and Motif
seem so alien to Mac hacks.)


Insert slug line in text files: this inserts the current name of the
file in any file _of type TEXT_. All other types are ignored. This
option is disabled when "Use text fileﾕs slug line" is selected in the
"Change file names" pop-up, for obvious reasons. Fair warning: do not
use this on Styled Text files! A Styled Text file (such as those
produced by Nisus) has the creator type 'TEXT', but there are pointers
into the text in the resource fork that will be hosed when the slug line
is inserted. Every one of those pointers will be "off" by the number of
characters in the slug line, which will produce interesting but not very
useful results. In the same respect, certain text editors (such as
BBEdit) store the current insertion point/selection in the resource
fork. These pointers will also be "off" by the size of the slug line,
but this is far smaller consequence.

(Kip asked during testing what might be the consequences for RTF files.
My answer: I don't know. I don't use RTF, so I don't know how fussy it
is. If you _do_, test this function on a _copy_ of your RTF file before
committing to it as a useful procedure.)

The slug line looks like this (everything between but not including the
rows of dashes):

-----
// Filename: nameOfFile

-----

"// Filename: " is for uniqueness in searching (as with my own
Torquemada the Inquisitor) and because anything (on one line) after two
slashes is interpreted as a comment in Think C and all C++ compilers
(viz., programmers can use Shane the Plane to comment their source files
with the name of the file). The extra return is there to be pretty
(grin). "nameOfFile", of course, is the current (possibly newly changed)
name of the file. The slug is prepended at the zeroth position in the
file, and everything after that is the literal text from the file. The
resource fork of the file is not changed.


Change Finder flags: okay, now we're back to this. This is complicated
enough that we're doing as much as we can to simplify it. For example,
with Drag & Drop batches, we are collecting information about the
pre-existing state of files and reporting it by means of graphic symbols
(thus making one of the busiest dialogs in Mac history, alas).

Two of these symbols are generic, and two are specific to a particular
check box.

The diamond symbol refers to the first file in the Drag & Drop batch. It
tells you that particular Finder attribute is _set_ in the first file in
the batch (this may not be true for _every_ file in the batch). If you
want to _retain_ this attribute (for the whole batch), you must check
the associated check box.

The circle symbol refers to _some_ (and possibly all) files in the
batch. It is used with "Remove custom icons" and "Remove PS font BNDLs"
to let you know that one or more files in the batch meets the criteria
for those check boxes. Since those functions are harmless on files that
_don't_ have the appropriate resources, it's safe to run them on (what
might be) a mixed batch.

The square symbol refers _only_ to "Make all in folder visible". It
tells you that one or more files in the folder(s) where files reside are
currently invisible.

The triangle symbol refers _only_ to "Install custom icons". It tells
you that there are "pasteable" icons in the clipboard.

(All of this will make more sense when we discuss these switches in
detail. But first:)

The Macintosh Finder works asynchronously. That is to say, it defers
some jobs that it judges to be less important until one of the following
things occurs: 1. it gets around to doing them, 2. the hardware is idle
enough that it feels confident to have enough time to do house-keeping,
or 3. an update is forced by some user- or software-initiated event. Why
is this important? First, because, with respect to these switches and
some others, we're pulling some cute stunts to force updates. And,
second, because the cute stunts don't work for every case, most notably
for "Stationery pad" and "Lock file name". So: keep in mind that if you
don't see an immediate update consequent upon the changes you have made,
you may need to close then open the folder (thus forcing an update).

Now then, these are the switches:

Lock file: This is the same as checking the Lock file check box in the
Get Info window. A locked file can't have its name changed (except from
Shane the Plane), can't be deleted (unless you hold down the option key
while selecting Empty Trash), can't be Saved under its own name, and
can't have a custom icon pasted into it (except from Shane the Plane).
(A previously locked file will generate the stupid Finder message when
accessed by Shane the Plane, but it's meaningless in this context.) A
diamond means the first file in the batch is locked.

Lock file name: a file with its name locked can't be renamed from the
Finder (it can be from Shane the Plane), and can't have custom-icons
pasted in (except from Shane the Plane). Lock file name is a nice
feature for managers and consultants who look after novice users. And,
ideally, all printer font files should have their names locked, since a
font ceases to work as soon as its name is changed. Take note that Lock
file name is updated slowly by the Finder, and that the file name may
_not_ be locked when the file is on the desktop (Finder bug?). A diamond
means the first file in the batch has its name locked.

Stationery pad: makes any document into a "template". Most
Stationery-aware applications will open it into an untitled window. Take
note that Stationery pad is updated slowly by the Finder. A diamond
means that the first file in the batch is a stationery pad.

Make invisible: in a Drag & Drop batch of files, makes all of them
invisible when checked. Interactively, makes the particular file visible
or invisible, depending on how the check box is set. The difference is:
you can't Drag & Drop an invisible file (grin). In consequence, there
will never be a diamond.

Make all in folder visible: for every file in the folder (but not
subfolders), makes all invisible files visible. Files you may not have
known were invisible (such as custom folder icons) will show up as well.
A square means one or more files in the _folder_ are invisible. (Because
files can be Dragged & Dropped from multiple folders (about which more
below), this will make visible all files in _all_ affected folders;
worth keeping in mind if you're looking for a surgical strike and not
the Scorched Earth policy.)

Has custom icon: sets or clears the flag _only_, depending on the state
of the check box. This by itself is pretty useless; it's this guy's two
children who do the interesting stuff. But: a diamond means that the
first file in the batch has this flag set.

Install custom icons: if there are icons in the clipboard, they will be
pasted into all files selected, and the custom icons flag will be set if
this check box is checked. If there are no icons in the clipboard, you
will be invited to copy some in. This is elemental coolness made flesh,
in my not very humble opinion (grin). Does nothing you couldn't do by
hand from the Finder, but Shane the Plane does it so much faster. Like
much of Mac-cool, this is nothing more than the sizzle on the steak; but
what sizzle! A triangle means there are icons in the clipboard at the
time of the Drag & Drop.

Remove custom icons: rips out all ICN#-family resources (with I.D.
-16455) found in the batch and clears the custom icons flag. A full set
of color icons takes up ｱ2.5K, so the disk space savings can add up over
a large batch (which you can then proceed to squander with the
above-mentioned switch? (grin)). A circle means that one or more files
in the batch have the custom icon flag set (implying the presence of
icon resources). Since only particular resource types with the I.D.
number -16455 are removed, this is harmless if used on a file that
_doesn't_ have any custom icons.

Has BNDL resource: sets or clears the bundle bit _only_ (again, this is
the dopey father to the wise child below). Changing the state of the
bundle bit (about which much more below) is usually a Real Bad Idea - no
consequences, but Norton Utilities (etc.) won't love you. A diamond
means the first file in the batch has its bundle bit set.

Remove PS font BNDLs: clears the bundle bit _and_ removes any
ICN#-family resources, the BNDL resource, the FREF resource, and the
font's owner resource (e.g., 'APSF' for Adobe PostScript Fonts). In
other words, what's left when this is done will be 'POST' and 'vers'
resources, if any. Works _only_ on files with type 'LWFN' (PostScript
Type 1 or Type 3 fonts from any foundry). The effect is to make copying
fonts as fast as copying any other like-sized documents. Further down,
we'll discuss why this is so. A circle means that one or more files in
the _batch_ are LWFNs with bundle bits set. As with "Remove custom
icons", this is harmless on files that _don't_ have the resource types
we're omitting. Fonts processed this way will have their creator changed
to sTp2 and will have a special Shane the Plane font icon applied to
them.

(Fair warning: This is a one-way street. Short of reverting to a back-up
of your fonts or going back to their original floppies, you can't put
this djinn back in the bottle. I can't imagine why you'd want to, but
it's only fair to mention that you are making a _permanent_ change to
the files.)


Parting shot: there is a lot of intelligent disabling going on with
these Finder flags. The intent behind this (freely confessed) modality
is to avoid doing potentially logically conflicting things
(quasi-)simultaneously. In truth, I could allow you to, for example,
make the batch of files invisible while making all others in the folder
visible. But it seems to me to invite confusion. In other cases, such as
"Remove PS font BNDLs", the disabled functions would contend with great
vigor, something like an alligator fight leaving two well-fed dead
'gators (grin). In any case, the admonition is: "But, gentlemen, you
_overdo_ the mode" (emphasis added). In software that is this dangerous
(as I will keep pointing out), it doesn't seem overdone to me...



5. Not for Flight Engineers only...

Okay, this is details regarding the details:

For starters, here's something cool: Because Shane the Plane is Apple
Event-aware, you can Drag & Drop batches of files from multiple folders,
then execute the whole widely dispersed batch when you hit Start. In
general, I expect this is mere frill, but I opted not to make it
_im_possible (it's possible by default) because I thought it might be
useful occasionally. Every time files are Dropped on the icon the entire
batch and all relevant folders are queried for the batchwise information
reported in Finder flags, so that information is always up to date for
the _whole_ batch (Remove custom icons and Remove PS font BNDLs) and for
_every_ folder from which files have been Dropped (Make all in folder
visible). This is important: if you check Make all in folder visible,
every file in _every_ affected folder will be made visible. Take note
also that Shane the Plane imposes a 256 file limit on the size of a
batch. This would not be a problem with files Dropped from one folder,
since 256 files in a single folder is slow death, but it might come up
with files Dropped from multiple folders. Normally my Drag & Drop stuff
imposes no limits (though I often say "512", just to establish that the
number is so large as to be meaningless). But in Shane the Plane we are
storing information about each file Dropped, and I wanted to keep the
memory commitment relatively small.

Near the point: the default memory partition of Shane the Plane is and
_must be_ 512K. If you watch About this Macintosh/the Finder, you'll see
that the bar never gets filled. You might think this means there is some
room for you to cut the partition. There isn't. While we're running,
we're allocating and disposing of large blocks of memory faster than the
Finder can record, so the heap often _is_ completely filled, even though
the Finder doesn't report that fact. This is not really a terribly large
problem, since we're checking to make sure we have the memory we need
before we commence to doing anything. If we're short on memory, we don't
do any work.

(For what it's worth: you should never change the memory partition on
utility software. You can safely change it on (Window-oriented)
applications software, because each opened Window has associated
dynamically allocated memory. If you can live with fewer windows, you
can live on less memory. But: in general, (Dialog-oriented) utility
software uses statically allocated memory and will malfunction if it
can't get all it needs. Certainly it will thrash a lot more, compacting
and re-compacting the heap to make space for itself (this is also true
of Window-oriented software), and it may act very flakey. Making the
partition smaller is an anachronism from the days when Macs were small
and stupid. I think it's best forgotten, with the rule of the road
being, if you want to change a partition, make it _larger_...)

As mentioned above, Shane the Plane's Apple Events-awareness makes it
(conceivably) possible to run it from an intelligent agent. I don't know
enough about scripting to tell you how to do this, but I _do_ want to
point out that, at a minimum, your script will need to be able to issue
a "return" (0x0D) or "enter" (0x03) keystroke. This is because Shane the
Plane _must_ be explicitly started by hitting the Start button. Since
that button is the default, you can "hit" it with the keystrokes, but
you _must_ post some kind of event to initiate execution. I don't know
if this is possible with Frontier or AppleScript alone, but certainly it
is possible using a QuicKey in combination with scripting software. To
do this properly, you should spawn a copy of Shane the Plane with all
the prefs you will want set and Saved; the Auto-pilot|Prompt radio group
should be set to "Auto-pilot". I don't know that I love this as an idea,
but it will work; it will take software that more or less requires
interaction and make it run as an unattended daemon's familiar.

Eminently nerd-like hack: every piece of software by me that has a
Preferences menu (Shane the Plane, Clip 'n' Save, ShawBerry, and the
forthcoming Mark My Words) stores its preferences in the resource fork
of the software itself. The Default prefs are stored in 'PREF' resource
128, and the Saved prefs are stored in PREF 129. When you Save
preferences, PREF 129 is re-written with your new settings. If you are
comfortable with ResEdit, you can use it to give yourself two sets of
stored preferences. Do this (on a _copy_ of Shane the Plane, of course):

1. Establish you second-favorite settings and Save preferences. Quit.

2. Open the copy of Shane the Plane from ResEdit, and navigate your way
to PREF 129. Select all and Copy.

3. Open PREF 128, Select All and Paste. Save and Close the file. The two
resources are now identical, with both containing your second-favorite
settings.

4. Launch Shane the Plane again and establish your (first-)favorite
settings and Save preferences. Now when you do Restore defaults, you'll
get your second-favorite settings, and when you do Restore saved prefs,
you'll get your (first-)favorite settings, which will also be loaded
automatically with every subsequent launch.

If you have DiskTop or DeskZap or some other utility that lets you
change Finder flags, you may wonder why Shane the Plane gives you access
to so _few_ of them. The reason is this: because most of them are
utterly useless. DiskTop and DeskZap give you access to _all_ of them,
even though most of them are without practical consequences. There is
one exception, which we're going to discuss. The Inited bit says that a
file has been seen (initialized) by the Finder; it has been recorded in
the Desktop database, and its position in the folder has been
established. What this means is that you will _never_ see a healthy file
that _has not_ been Inited. If you clear this switch in DiskTop/DeskZap,
the Finder will reinitialize the file in short order, with the
(possible) observable outcome being that the file will move in its
folder. Originally, Shane the Plane was going to make the Inited bit
available to be changed, but we left it out because it's so
preternaturally useless. _However,_ there _are_ a few occasions where
we're changing it on our own: the Inited bit is cleared in instances
where the Finder is reluctant to update in a timely fashion (as with
Lock name and Stationery pad). And: the Inited bit is cleared when the
result of a switch setting is to create a new file from the old (Install
custom icons, Remove custom icons, Remove PS font BNDLs, and Insert slug
line in text files).

Take note with respect to the above paragraph: except for changing the
Inited bit in the few instances named, we are being careful to change
only the things you ask to have changed. So, for example, even though
the effect of Remove custom icons is to create a new file identical to
the old but with the icons omitted, the created/modified dates and times
will _only_ change if you explicitly change them. Likewise, all of the
goofy Finder flags to which you do not have access from Shane the Plane
are passed unaltered.

I wanted to say a few words about Make invisible. For the most part, I
think it's a Real Bad Idea. Apple explicitly advises against it, with
what seems to me to be good reason. On the other hand, I myself have
particular need to make a certain few files invisible. So what I have to
say is this: if you don't have an overwhelmingly good reason to make
files invisible, don't do it. They do not call attention to their
presence, so they can soak up valuable hard disk real estate without
your knowing about it. It is _because_ they are potentially so
pernicious that Shane the Plane looks for them wherever he goes,
offering you the chance to make them visible.

Regarding Remove PS font BNDLs: Did you ever double-click on one of your
font folders, then have to reboot because the damn thing wouldn't open?
Did you ever wonder why it takes so long to copy a font folder? Well,
here's a real knee-slapper: it's because the font vendors are
deliberately crippling your Macintosh with advertising!

To quote Dave Barry: I am not making this up!

If you drop an unaltered PostScript printer font file on Shane the
Plane, you'll see that it "Has BNDL resources". What does this mean...?

The BNDL resource (itself) associates a file's owner resource (same name
as the Creator type), it's FREF resource, and its icons. The presence of
the BNDL resources (with the bit set) occasions an entry into the
Desktop database for the file (almost always executable software). The
Desktop DB entry tells the Finder what icons to use for files
(associated FREF entries) created by the software. Because of this,
ordinary files don't need BNDL resource of their own.

The most notable exception to this logic is PostScript printer font
files, each of which has a set BNDL resources. Why? For reasons of
vanity and advertising. Since there is no application associated with
fonts, they'd come up with plain document icons without their BNDLs.
It's the BNDLs, not the +/- 400 bytes of excess resource baggage, that
make fonts so slow to copy, etc.; each one must be entered in the
Desktop DB for no good reason.

To make this clear: _because_ PostScript printer font files have BNDL
resources, the Finder must spend a _lot_ more time dealing with each one
than it would have to do if the BNDL resources were stripped and the
"Has BNDL resources" bit cleared. This is what Shane the Plane does if
you select "Remove BNDL resources". It is not enough to simply clear the
bit, since disk-fixing utilities like The Norton Utilities will simply
reset it at their next opportunity. But after the resources are removed
and the bit cleared, the printer font files will behave as normal
documents. They'll copy as fast as any other like-sized documents and
their folders will open as quickly as other folders with that many files
in them (still not awfully fast to be frank, but fast_er_). They'll
still be perfectly fine _as fonts_, since, qua fonts, all that matters
are the POST resources (Type 1) or the contents of the data fork (Type
3), all of which is retained. All we're doing is ripping out the
Mac-crippling advertising.

(Take note: this function will change _only_ files of type 'LWFN', but
it will change LWFNs with any creator (that is, from any vendor).)

BNDL issue 1: making this change may violate your license agreement with
your font vendor(s). If it does, you're on your own, but I'd _love_ to
hear the font vendors assert their legal right to cripple and crowd your
computer with entirely non-functional, hyper-redundant advertising.
Unlike the FreeWare utility DeBNDLer (which does not work for me), we
are not preserving the owner resource as a 'vers' resource, which means
the copyright information will not be visible from the Get Info window
_unless_ the font has 'vers' resources of its own (as do, for example,
all Agfa fonts). The font is still protected by copyright however! (I
would say "obviously", but there is evidence enough that people find
this little bit of obviousness too easy to overlook.) Moreover, it is
still _explicitly_ copyrighted in the POST resources and/or data fork.
It will have a Shane the Plane creator and a distinctive Shane the Plane
printer font icon, but it is still and always the copyrighted
intellectual property of its original vendor, usable and transferrable
only according to the terms of the license agreement. In other words, I
can't believe a judge would fault you for stripping out the BNDLs,
especially given their hostile perniciousness. But I have no doubt at
all that a judge would (quite properly) nail you to the wall for using
Shane the Plane as your excuse to steal fonts.

BNDL issue 2: because font folders take so long to open when the fonts
still have their BNDLs (the folders _do_ open, it just takes longer than
normal mortals can stand to wait), I have made a folder-aware Drag &
Drop utility called Oscar the (Moderately Awe-Inspiring) Cat (who is
pictured in About Shane the Person). Oscar the Cat removes the BNDLs and
clears the BNDL bit from any LWFNs found in that whole folder
_hierarchy_. In other words, it starts immediately within the folder
Dropped and works its way down that whole folder tree. Oscar the Cat
ships only with the unrestricted version of Shane the Plane, and is
licensed only to purchasers of the unrestricted version of Shane the
Plane. You would use it like this: do all your existing fonts at once
with Oscar the Cat, then process newly purchased fonts with Shane the
Plane.

Here's an interesting question: what is the point of "Change file
names/Use text file's slug line"? This is Kip Shaw's agenda, his methods
are covered in detail in Appendix A. His text is eminently worth
reading, since he is developing a hyper-efficient text-processing
methodology around Shane the Plane and other tools. But here's the short
course:

1. Suppose you are going to be using a bunch of utilities like mine,
each of which will add its own extension to the files it produces.
Before doing anything, you could run the originals through Shane the
Plane, checking "Insert slug line in text files". This will put the
file's own true original name within it. Then you run all the
extension-appending utilities. When you finish, take the final versions
of the files and Drop them on Shane the Plane. Check "Change file
names/Use text file's slug line". The files will be renamed with the
true original names of the true original files.

2. This is Kip's coolest trick the quick way: suppose you have a great
batch of similar files. My own utilities (such as Torquemada the
Inquisitor) will do the same stuff to each file of a batch, but if you
have to make global changes in an interactive editor, it would be far
better to have all the text in one file. Otherwise, you'll have to make
each global change in each file - slow and error-prone. So what you
could do is this:

a. Run the originals through Shane the Plane, checking "Insert slug line
in text files". This will put the file's own true original name within
it.

b. Concatenate the whole batch of files (using my own Cat o' Seven
Tails, for example).

c. Do all of your editing on the concatenated file, using either your
interactive editor or batch-oriented utilities.

d. Segment the concatenated file using my Caesura. Divide at
"// Filename:" (which is one reason why this text is so odd) and select
"Divide at paragraph-ending BEFORE string". This will chop the files
back up in their original segments. But: their names will be
auto-generated by Caesura. So:

e. Run the newly created segments through Shane the Plane, checking
"Change file names/Use text file's slug line". The files will be renamed
with the true original names of the true original files.

If your goal is to show these files as "galleys", you can elect to
retain the slug line on the second pass through Shane the Plane. That
way, other people editing paper copies of the text will know which file
they are working on. Otherwise, you can elect to omit the slug line. As
discussed above, the slug line is omitted automatically when the
Auto-pilot|Prompt radio group is set to "Auto-pilot". When it is set to
"Prompt", you will be prompted once per session to discover what you
want to do.

Shane the Plane and aliases: Shane the Plane resolves aliases to the
_true file referred to by the alias_. That is to say: if you Drop an
alias of a file on the icon, the alias itself will not be altered, the
file _referenced_ by the alias will be altered. Forewarned is forearmed!

Finally, as your reward for wading through all this stuff: you can abort
a Drag & Drop batch of files after you hit the Start button by holding
down the Command and Period keys. The abort will happen _between_ files,
so anything already started will be fully done, and anything unstarted
will be undone. Rather than trying to figure out what to do next, we're
just beeping twice then quitting, to give you the opportunity to do what
you need to before proceeding. Given that I'm mentioning it this late in
the manual, you might guess that I think this abort feature is a Real
Bad Idea. I've only implemented it so that you can contain the damage,
if you realize late that your settings are a horrible mistake. My main
advice is: this software is DANGEROUS, so don't make horrible mistakes!
(grin)



6. About Greg Swann...

Okay, here's the deal: I'm not just a developer, I'm a user of software
as well. I make about half of my money doing Desktop Publishing. In
consequence, I have a pretty clear idea of how to focus utilities
designed to plug gaps in the functionality of major applications. I am
quite sure there are a _lot_ of developers brighter than I am. But the
evidence of experience suggests that few of them have my advantage of
living on both sides of the line, so to speak.

What does this mean?

First, it means that I have written a _lot_ of mission-critical
utilities in support of the software categories of interest to me: file
management, font management, automated text processing,
PostScript-processing, and automated DTP-software preparation. All but
four of these utilities are FreeWare (the exceptions being Shane the
Plane and the three packages discussed below) and are available from
Info-Mac and other electronic information services (including any
service offering access to the Arizona Macintosh User's Group
BBS-In-A-Box CD-ROM).

Second, it means that if you are likewise interested in these software
categories, it behooves you to support my work. Fanmail is always nice,
of course, but remuneration is the sincerest form of flattery (grin).
Seriously: this is a business, even if a microscopically small one. It
has been worthwhile so far because the other things commanding my
attention have not been as lucrative. But that is changing (of course,
and obviously, _because_ of all the software). I can make a _lot_ of
money writing custom software for contracted clients. And I can
streamline my own production work without having to monkey-proof and
document my tools. So: if I am to keep doing this, I have to make it
pay. If you _want_ me to keep doing it, you have to pay me. It's that
simple.

In many ways, retail software is simpler. You pay or you don't play, and
no one has any illusions. The difference is, the developer needs a
_much_ larger capital commitment, and he needs to surround himself with
babbling morons in suits who might - just possibly - be good for
something other than chuckling about football. Electronically
distributed software gets around that trap, but introduces the problem
exposed here: the ambiguity of the sales transaction results in a lot of
prostrate begging by developers. I don't beg, but I don't work for free
except on my own terms for my own good reasons.

There are three possible "futures" for authors of electronically
distributed software. 1. The rewards do not justify the effort, so the
author goes and plays tennis or something. 2. The author produces
software as an after-work hobby and continues to do so more or less
irrespective of user-response (some of the best and worst FreeWare comes
out of this category). 3. The author's growing reputation results in him
getting more contracted custom programming work, worth more money, to
the point that he no longer has time to produce electronically
distributed software.

It is the last that is happening to me, and this is why you need to
support my work, if you want it to continue. I'll do all right whether
I'm working on problems that confront you or on the problems of some
corporation. But: if you are using software by me that has a commercial
version (and all of them are discussed here), and if you want me to
_continue_ thinking about your problems, rather than the problems of
Consolidated MediCalc - you know what to do...

These are my commercial programs:

XP8 - a very intelligent file filter that cleans up and makes the
filthiest text QuarkXPress-ready. Among many other features, it
offers DOS-file reformatting, financial-text clean-up, garbage
disposal, typographic quality enhancement, and the best quote
conversion we know of. The ShareWare version of XP8 (v1.0.0) can be
found in CompuServe's Desktop Publishing Forum (GO DTPFORUM),
Library 5, under the name XP8.SEA or in the Info-Mac archives as
GST-XP8Demo.sit. The current commercial version is v1.0.7 and offers
a great many enhancements over the ShareWare version.

Torquemada The Inquisitor - batch global search and replace software
with wildcards, pattern matching, string substitution, et very
cetera. With Drag & Drop under System 7 and above, you can run up to
640 searches on up to 128 files in one batch. Features the most
intelligent case-conversion we know of. The most-recent FreeWare
version (1.1.0) can be found under the name TORQUE.SEA in Library 5
or in the Info-Mac archives as GST-TorqueDemo.sit. The current
commercial version is 1.3.0, offering a great many enhancements,
including new "wildthings" and a _lot_ of new User Interface power.
The commercial version ships with Torquemada's Ghost, a scriptable,
backgroundable Torquemada. A DemoWare version of Torquemada's Ghost
is available as TGHOST.SEA in Library 5 or in the Info-Mac archives
as GST-TGhostDemo.sit.

Shane the Plane 2.0.2 - file and font attribute editing utility.
Interactively or in Drag & Drop batches, permits you to change the
Creator/Type of files, their created/modified dates and times, a
host of significant Finder flags, plus a lot more. Makes files
invisible/visible, makes fonts behave like files by removing their
BNDL resources, batch "pastes" custom icons, intelligently renames
and/or "slugs" files, et very cetera. A demonstration version (fully
functional but limited to 32 launches) can be found in Library 12
under the name SPDEMO.SEA or in the Info-Mac archives as
GSU-STPDemo.sit.

Mark My Words - a very elaborate MS-Word binary to QuarkXPress Tags
text filter. It eats Word 4.0, 5.0 or 5.1 files, interactively or by
Drag & Drop, and converts the binary to QuarkXPress tagged text. You
can elect to include or omit any feature of Word's styling, and many
features can be converted from their WP-like form to their DTP-like
form (e.g., underscoring to italic). With Em Software's Xtags
Xtension, picture and text boxes (including Word's tables) can be
retained. A demonstration version (fully functional but limited to
32 launches) can be found in Library 12 under the name MMWDEM.SEA or
in the Info-Mac archives as GST-MMWDemo.sit.

(While I've vectored all the files toward CIS and the internet, my
primary haunt, they are also available on other services, and on any BBS
which has the most recent version of AMUG's BBS-In-A-Box CD-ROM on
line.)

All of these programs are sold on the same terms: (US)$50 each, per
license. Two to 10 licenses are $45 each. For 11 or more licenses you're
better off buying a site license. All of this is explained in the
registration software supplied with this archive.

These programs are included on the distribution disk for the
unrestricted version of Shane the Plane:

* Shane the Plane v2.0.2 - discussed here as some length (!)

* Oscar the Cat v1.0.0 - PostScript font BNDL removal software licensed
as a premium to purchasers of Shane the Plane.

* XP8 v1.0.0 - ShareWare version of the commercial software

* Torquemada the Inquisitor v1.1.0 - FreeWare version of the commercial
software

* Mark My Words v1.0.0 - DemoWare version of the commercial software
(when it becomes available)

* Caesura v1.0.0 - FreeWare file segmentation software

* Cat o' Seven Tails - FreeWare file concatenation software

Plus some other stuff...



7. Conclusion...

Jeez, haven't you had _enough_...? (grin)

Seriously: that's it. If you have any questions or problems, the easiest
way to get hold of me is by email at:

    [e-mail]

If you can't do that, you can snail mail me at:

    Greg Swann
    3608 West Cochise Drive
    Phoenix, AZ 85051



Very Best,



Greg Swann

8/1/98





Appendix: Real World Shane the Plane

... or ...

What good is a shortstop without the other infielders?



by Kip Shaw



Fleet of foot and with a mighty arm, Shane covers a lot of ground
deep in the hole. But once he's snagged a wicked line drive, who's
he going to throw it to? Thanks to Manager Greg Swann (whose team
is aptly called the "Swanney Ribbers" because they are fond of
jokes), some shrewd trades were made: Protecting second base is
"Cat o' Seven Tails," and over at first is that fearless lefty
"Caesura." Some may say, "But are they as good as Tinker, Evers,
and Chance from the glory days of the Chicago Cubs?" You bet they
are. Here's how they turn a triple play.

First, let's describe the wicked line drive that is streaking
toward Shane: it's a batch of text files generously provided by one
of your friendly clients. Unless you've housebroken this client,
the files no doubt will be filled with garbage. Not only will you
need to weed out all the multiple spacebands, multiple carriage
returns, etc., but you might also be called upon to do some
copyediting - perhaps relatively simple stuff like making all the
"a.m."s and "p.m."s consistent, or maybe a whole lot more. Before
you plunge into these tasks, let Shane snare this line drive - drag
& drop all the files on Shane and do this: check *on* the "Insert
slug lines in text files." As previously described in these docs,
this will put the filename at the beginning of each file.

The slug line looks like this (everything between but not including
the rows of dashes):

-----
// Filename: nameOfFile

-----

with "nameOfFile" being (surprise) the name of the file that appears
in a Finder window and the file's title bar. If you're not happy
with the names of the files - perhaps the client made them
unnecessarily long or uselessly nondescriptive - then also do this
in Shane at the same time: check *on* the "Change file names"
checkbox and select "Prompt individually" in the popup. In this
way, you can quickly change some or all of the file names and
*also* have the new names inserted as a slug line in the text
files.

Now that all the files are properly slugged, it's time for Shane to
whip the ball over to the secondbaseman, "Cat o' Seven Tails." For
those of you who might not be aware of Cat's prowess, let me wax
eloquent: Cat does one thing, and does it lightning fast - he
concatenates. For those of you who don't know what "concatenate"
means - look in the dictionary! <g> Okay, I'll tell you -
"Concatenate. To connect or link in a series or chain." So, if you
drag & drop all your now-Shaned client's files onto Cat, they will
be joined together (in the order they were selected in the Finder)
into one file, aptly named "Concatenated files." Why, you ask,
bother to join all the files together? Why not continue to work on
them individually? Sure, you could work on them separately, but
often - especially when editing is involved, and you need to refer
quickly back and forth between files - it can be a whole lot easier
if they're all in one file. And don't worry - once the ball gets
over to our first baseman, you will easily be able to split them
apart again.

But we're still at second base with Cat. Do whatever copyediting you
need to do on the "Concatenated files" file. Run it through XP8 and
Torquemada (who are other stellar members of the Swanney Ribbers).
Massage that text to your heart's content! Once done, you might have
a file now named "Concatenated files.XP8.TQM.XP8.TQM.SB!." ("SB!" -
what's that, you ask? Another member of the team - ShawBerry - a
true hall of famer. But that's another story.)

Okay. So Cat and his teammates have now served up something like
"Concatenated files.XP8.TQM.XP8.TQM.SB!." Time to sling that
over-extended filename to the fearless firstbaseman, Caesura. Some
fans of a rival team have spread malicious rumors that Caesura is
Cat's evil twin - but don't pay any attention to this gossip. The
slander started when it was discovered that Caesura has only one
goal in life - to undo what Cat has done. Caesura *splits* a file
into segments. What these rival fans didn't realize, though, is
that Cat and Caesura work in harmony. Here's how:

First, do yourself a favor: shorten the bloated filename to
something like "Catted" because Caesura likes to add its own
extension to the file name, which will makes things even more
unwieldy. Then boot up Caesura and you'll be asked two things: 1)
"Specify a string at which to divide" and 2) whether to "Divide at
paragraph-ending BEFORE string" (the default) *or* "Divide at
paragraph-ending AFTER string." Thanks to shortstop Shane, our
string of choice is easy: "// Filename" - and, therefore, we should
use the "Divide before string" default. Then, click on Caesura's
"Start" button and navigate in the dialog over to our baseball -
"Catted" - then click on the "Open" button. Caesura will now split
the catted file into the original segments that your client gave
you. Only problem is that the filenames will be useless - Caesura
simply appends a numerical extension to each of the segments -
e.g., "Catted.001" - not very descriptive!

But like any peerless infielders who have just completed a triple
play, the ball is flung around the horn - back to Shane. Drag &
drop the Caesura-segmented files onto Shane, and in the "Change
file names" popup, select "Use text file's slug line." (You might
also want to change the creator/type to your favorite text editor
at this point to rid yourself of the Caesura creator/type.) Just
like magic (which any fan will tell you baseball truly *is*), Shane
restores the original file names. You'll notice that the first
Caesura-segment's file name hasn't changed - it's still
"Catted.001." That's because it's garbage - a non-file - because
there obviously wasn't any text found before the first "//
Filename" string that was the marker you entered in Caesura. You
can trash it.

That's it. Inning over. And like all triple plays, it takes less
time to *do* than to *describe.*